home *** CD-ROM | disk | FTP | other *** search
/ Programming Languages Suite / ProgramD2.iso / Languages / MS Cobol4.5 / DOCS / OPTIMIZE.DOC < prev    next >
Text File  |  1991-06-01  |  13KB  |  331 lines
  1.  
  2.                        CREATING OPTIMIZED PROGRAMS
  3.                        ===========================
  4.  
  5.   This document should be regarded as a supplement to the chapter Writing
  6.   Programs in your Operating Guide. It gives some guidelines which, if
  7.   followed, allow your COBOL system to optimize fully the native code
  8.   produced for your programs - resulting in smaller and faster applications.
  9.  
  10.  
  11.   TABLE OF CONTENTS
  12.  
  13.       INTRODUCTION
  14.       DATA DIVISION CONSIDERATIONS
  15.           Data Types
  16.           Linkage Items
  17.           Large Data Divisions
  18.       PROCEDURE DIVISION CONSIDERATIONS
  19.           Arithmetic Statements
  20.           Alphanumeric Data Manipulation
  21.           Tables
  22.           Conditional Statements
  23.           Loops and Subroutines
  24.           CALL statements
  25.           Large Procedure Divisions
  26.       COMPILER DIRECTIVES
  27.       EXAMINING THE NATIVE CODE
  28.  
  29.  
  30.   INTRODUCTION
  31.  
  32.   The guidelines are set out in a "Do this" / "Don't do that" style. Do
  33.   remember that these are only guidelines; programs that do not conform to
  34.   these guidelines will still run correctly, just less efficiently.
  35.  
  36.   For further information on many of the topics discussed in this document,
  37.   see chapter Compiling and chapter Writing Programs in your Operating
  38.   Guide.
  39.  
  40.  
  41.   DATA DIVISION CONSIDERATIONS
  42.  
  43.   Data Types
  44.   ----------
  45.    o  Use unsigned COMP-5 or COMP-X numeric data items; preferably COMP-5.
  46.  
  47.    o  Use 2-byte COMP-5 items rather than single byte fields for arithmetic.
  48.  
  49.    o  Do not use numeric items that occupy more than 4 bytes of storage.
  50.  
  51.    o  Do not redefine COMP-5 items to access individual bytes; if access to
  52.       individual bytes is required use COMP-X.
  53.  
  54.    o  Use edited items only when necessary and use only simple ones such as
  55.       ZZ9. If possible use them in a subroutine so the total number of
  56.       edited moves in your program is kept as small as possible.
  57.  
  58.    o  Do not use items defined as EXTERNAL.
  59.  
  60.    o  Align items on even byte boundaries and ensure the stride of a table
  61.       is an even number, if possible a power of 2 (pad the table as
  62.       necessary). The stride of a table is the size of one element; for
  63.       example, the stride of the following table is 2 bytes:
  64.  
  65.       01 a occurs 10.
  66.           05 b pic x
  67.           05 c pic x.
  68.  
  69.  
  70.   Linkage Items
  71.   -------------
  72.    o  Don't make many references to items defined in the Linkage Section
  73.       (examples: linkage parameters; x"D0" allocated memory). It is more
  74.       efficient to move the data to Working-Storage, manipulate it there,
  75.       then move it back again.
  76.  
  77.    o  If a parameter is optional you can detect its presence  using the
  78.       following syntax:
  79.  
  80.       IF ADDRESS OF linkage-item NOT = NULL
  81.  
  82.  
  83.   Large Data Divisions
  84.   --------------------
  85.    o  Ensure the size of your Data Division is less than 64 kilobytes (64K),
  86.       keeping the total size as small as possible. In the Procedure Division
  87.       the RTS can swap segments, but it cannot page the Data Division.
  88.  
  89.    o  Redefine memory that is only used during certain phases of a program's
  90.       execution so that it can be shared by several routines.
  91.  
  92.    o  If more than 64K of data is required use a heap, or use the x"D0"
  93.       COBOL System Library Routine to allocate the space dynamically. But
  94.       remember x"D0" items have the disadvantage of being Linkage items.
  95.  
  96.    o  Do not use the NOSMALLDD directive unless you have no choice. If
  97.       necessary (normally for parameters passed to your program by external
  98.       programs), use the SEGCROSS directive so that the performance of most
  99.       data accesses is not affected.
  100.  
  101.  
  102.   PROCEDURE DIVISION CONSIDERATIONS
  103.  
  104.   Arithmetic Statements
  105.   ---------------------
  106.    o  Use simple forms (for example, ADD a TO b) of the arithmetic verbs and
  107.       do not use the COMPUTE verb.
  108.  
  109.    o  Do not use the GIVING form of these verbs. If necessary create
  110.       temporary variables and code several simple statements to achieve the
  111.       same result. For example, write:
  112.  
  113.           MOVE a TO c
  114.           ADD  b TO c
  115.  
  116.       rather than:
  117.  
  118.           ADD a TO b giving c
  119.  
  120.    o  Do not mix items of different sizes in an arithmetic statement (for
  121.       example, try to use all 2-byte items or all 4-byte items).
  122.  
  123.    o  Do not use the REMAINDER, ROUNDED, ON SIZE ERROR or CORRESPONDING
  124.       phrases.
  125.  
  126.  
  127.   Alphanumeric Data Manipulation
  128.   ------------------------------
  129.    o  Reference modified fields are optimized if coded in one of the
  130.       following forms:
  131.  
  132.       item (literal:)
  133.       item (literal:literal)
  134.       item (literal:variable)
  135.       item (variable:variable)
  136.       item (variable + literal:literal)
  137.       item (variable - literal:literal)
  138.       item (variable + literal:variable)
  139.       item (variable - literal:variable)
  140.  
  141.       Other forms of reference modification are inefficient.
  142.  
  143.    o  If the offset or length of the reference modification is a data item,
  144.       use a 2-byte COMP-5 item. Define it in Working-Storage.
  145.  
  146.    o  In a MOVE statement, have the source item the same size as or larger
  147.       than the target. This prevents space-padding code being generated.
  148.  
  149.    o  Do not use the INITIALIZE verb.
  150.  
  151.    o  Do not use the CORRESPONDING option of the MOVE verb.
  152.  
  153.    o  Do not use the STRING or UNSTRING verbs - they create a lot of code.
  154.       For manipulating filenames use the COBOL System Library Routines
  155.       CBL_SPLIT_FILENAME and CBL_JOIN_FILENAME. For other purposes, create
  156.       your own loops; they will almost always be more efficient.
  157.  
  158.  
  159.   Tables
  160.   ------
  161.    o  The optimal definition for a subscript is a 2-byte COMP-5 item.
  162.  
  163.    o  Subscripts for items that have the same stride and are used in
  164.       consecutive statements are optimized so that they are only evaluated
  165.       once. For example:
  166.  
  167.           01 A PIC XX OCCURS 10.
  168.           01 B PIC XX OCCURS 10.
  169.           01 C PIC XX OCCURS 10.
  170.           01 D PIC XX OCCURS 10.
  171.               . . .
  172.               MOVE A(I) TO B(I)
  173.               IF C(I) = D(I)
  174.                   DISPLAY "PASS"
  175.               END-IF
  176.  
  177.       would result in the subscript I being evaluated only once, although it
  178.       is used four times in two statements.
  179.  
  180.    o  When compiling your program for use in production, use the NOBOUND
  181.       directive so that subscript range checking code is not included. Use
  182.       BOUND only when debugging.
  183.  
  184.  
  185.   Conditional Statements
  186.   ----------------------
  187.    o  Do not use large EVALUATE statements. They are compiled into a series
  188.       of IF ... ELSE IF ... statements where the value of the expression is
  189.       derived separately for each WHEN clause.
  190.  
  191.    o  Order an EVALUATE statement so that the most commonly satisfied
  192.       condition is tried first. Do not use complex expressions or Linkage
  193.       items as conditions in an EVALUATE statement; instead, calculate the
  194.       value yourself in a Working-Storage item and use that item.
  195.  
  196.    o  Comparing for equality or inequality is more efficient than testing
  197.       for "greater than" or "less than", especially with COMP-X or
  198.       alphanumeric items.
  199.  
  200.    o  In both alphanumeric and numeric comparisons, have the source and
  201.       target items the same size.
  202.  
  203.    o  Use a GO TO ... DEPENDING statement if the range of possible values is
  204.       fairly close. Although this construct has the disadvanage of not being
  205.       particularly suited to structured programming, it is efficient.
  206.  
  207.  
  208.    Loops and Subroutines
  209.    ---------------------
  210.    o  When incrementing or decrementing a counter, terminate it with a
  211.       literal value rather than a value held in a data item. For example, to
  212.       execute a loop n times, set the counter to n and then decrement the
  213.       counter until it becomes zero, rather than incrementing the counter
  214.       from 0 to n.
  215.  
  216.    o  The range of an out-of-line PERFORM statement should not contain the
  217.       end of another perform range. (One way to ensure this is to perform
  218.       sections only, not paragraphs; however, with carefully structured
  219.       programming this should not arise). You can then compile your program
  220.       with the generator directive NOTRICKLE, which lets the compiler
  221.       produce more efficient code. This coding style generally gives you a
  222.       more easily maintained program too.
  223.  
  224.    o  Do not use PERFORM a THRU b as this too can lead to trickling code.
  225.  
  226.    o  Use PERFORM para N TIMES but not the equivalent in-line perform.
  227.  
  228.    o  Put commonly used pieces of code in sections or paragraphs and PERFORM
  229.       them. This is saves space for any statement used more than once that
  230.       produces more than 4 bytes of generated code (in a NOTRICKLE program).
  231.       It is often beneficial even on single statements, for example edited
  232.       moves, subprogram calls or file I/O.
  233.  
  234.  
  235.   CALL statements
  236.   ---------------
  237.    o  Try to limit the number of CALL statements a program makes, if
  238.       necessary by avoiding splitting it into too many subprograms.
  239.  
  240.    o  CALL statements that do not alter the RETURN-CODE special register or
  241.       whose effect on RETURN-CODE are of no interest should use a calling
  242.       convention of 4 (the checker directive DEFAULTCALLS can be used to set
  243.       this globally).
  244.  
  245.    o  Calls to the COBOL System Library Routines that carry out logical
  246.       operations (CBL_AND, etc) are optimized by the generator to actual
  247.       machine logical operations, providing the parameters are 8 bytes long
  248.       or less. These too should use a calling convention of 4.
  249.  
  250.    o  Use the generator directive NOPARAMCOUNTCHECK if your program is
  251.       always called with the correct number of parameters, or if it does not
  252.       reference unsupplied parameters. Most programs will fall into this
  253.       category.
  254.  
  255.  
  256.   Large Procedure Divisions
  257.   -------------------------
  258.    o  On DOS or OS/2, code segments are limited in size to 64K. Do not let
  259.       the generator decide where to break your program into segments.
  260.       Instead segment the program manually, that is, by using the segment
  261.       number on a section header, so you can choose where to split it. Avoid
  262.       inter-segment PERFORM and GO TO statements.
  263.  
  264.    o  If appropriate the memory needed can be reduced by manually segmenting
  265.       a procedure division smaller than 64K. As the RTS can segment-swap
  266.       procedural code this is rarely necessary.
  267.  
  268.  
  269.   DIRECTIVES
  270.  
  271.   A number of checker and generator directives can be used to enable the
  272.   native code for a program to be better optimized. Some of these directives
  273.   must be used with care; ensure that the behavior that you get with these
  274.   directives is acceptable.
  275.  
  276.   Use the following directives when checking and generating your programs:
  277.  
  278.        NOALTER
  279.        ALIGN(2)
  280.        NONESTCALL
  281.        OPTSIZE
  282.  
  283.    Use with care:
  284.  
  285.        NOTRICKLE
  286.        DEFAULTCALLS(4)
  287.        NOPARAMCOUNTCHECK
  288.  
  289.    Use when compiling for production:
  290.  
  291.        NOANIM
  292.        NOBOUND
  293.  
  294.    Other suggestions (to help prevent inefficient coding):
  295.  
  296.        REMOVE "UNSTRING"
  297.        REMOVE "STRING"
  298.        REMOVE "GIVING"
  299.        REMOVE "ROUNDED"
  300.        REMOVE "COMPUTE"
  301.        REMOVE "ERROR"
  302.        REMOVE "ALTER"
  303.        REMOVE "INITIALIZE"
  304.        REMOVE "CORRESPONDING"
  305.        REMOVE "TALLYING"
  306.        REMOVE "THRU"
  307.        REMOVE "THROUGH"
  308.  
  309.  
  310.   EXAMINING THE NATIVE CODE
  311.  
  312.   You can see the generated code produced for your program, by using the
  313.   generator directives ASMLIST() SOURCEASM to produce a .GRP file containing
  314.   the assembler and source listing in the same file.
  315.  
  316.   If the generator considers a statement for optimization, but finds that it
  317.   does not conform to the necessary guidelines, the word "BADCODE" appears
  318.   next to the statement, on the right-hand side of the listing. But some
  319.   statements that have generated inefficient code will not have been
  320.   identified in this way; you can usually spot these by looking for a single
  321.   statement that has generated a lot of assembler code.
  322.  
  323.   Try to eliminate or at least reduce the inefficient statements in your
  324.   program. But be aware of the law of diminishing returns; as you improve
  325.   the efficiency of your program, you will eventually reach a point where a
  326.   lot of extra effort will give only small further gains.
  327.  
  328.   ==========================================================================
  329.   Copyright (C) 1991 Microsoft Corporation
  330.   Copyright (C) 1991 Micro Focus Ltd
  331.